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ABSTRACT 

The  combination  of  high-resolution  multi-spectral  satellite  imagery  and  advanced  COTS  object-oriented  image 
processing  software  provides  for  an  automated  terrain  feature  extraction  and  classification  capability.  This  information, 
along  with  elevation  data,  infrared  imagery,  a  vehicle  mobility  model  and  various  meta-data  (local  weather  reports, 
Zobler  Soil  map,  etc...),  is  fed  into  automated  path  planning  software  to  provide  a  stand-alone  ability  to  generate  rapidly 
updateable  dynamic  mobility  maps  for  Manned  or  Unmanned  Ground  Vehicles  (MGVs  or  UGVs).  These  polygon 
based  mobility  maps  can  reside  on  an  individual  platform  or  a  tactical  network.  When  new  information  is  available, 
change  files  are  generated  and  ingested  into  existing  mobility  maps  based  on  user  selected  criteria.  Bandwidth  concerns 
are  mitigated  by  the  use  of  shape  files  for  the  representation  of  the  data  (e.g.  each  object  in  the  scene  is  represented  by  a 
shape  file  and  thus  can  be  transmitted  individually).  User  input  (desired  level  of  stealth,  required  time  of  arrival,  etc. . .) 
determines  the  priority  in  which  objects  are  tagged  for  updates.  This  technology  was  tested  at  Fort  Knox,  Kentucky 
October  1 1th  -  15th  2004.  Satellite  imagery  was  acquired  in  a  near-real-time  fashion  for  the  selected  test  site.  Portions 
of  the  resulting  geo-rectified  image  were  compared  with  surveyed  range  locations  to  assess  the  accuracy  of  the 
approach.  The  derived  UGV  Path  Plans  were  ingested  into  a  Stryker  UGV  and  the  routes  were  autonomously  traversed. 
This  paper  will  detail  the  feasibility  of  this  approach  based  of  the  results  of  this  testing. 

1.  INTRODUCTION 

When  you  think  about  robotic  path  planning  what  comes  to  mind?  The  Floyd- Warshall  algorithm,  A*,  D*,  Johnson's 
algorithm,  etc...  And  when  you  think  about  autonomous  vehicles,  what  comes  to  mind  -  Tank  Automotive  Research 
Development  and  Engineering  Center  (TARDEC)  Robotic  Systems,  Army  Research  Lab’s  (ARL)  XUV,  Carnegie 
Mellon  University’s  (CMU)  Sandstorm,  Defense  Advanced  Research  Projects  Agency’s  (DARPA)  PerceptOR 
program?  What  do  all  these  things  have  in  common?  For  the  algorithms  to  function  and  for  the  vehicles  to  navigate, 
they  all  need  detailed  information  about  the  environment  around  them.  And  not  just  the  local  data  readily  available 
from  the  vehicles  on  board  sensors,  but  detailed  a  priori  data  of  the  region  the  vehicle  will  traverse.  Some  of  the  most 
highly  advanced  Unmanned  Ground  Vehicles  (UGVs)  of  our  day  depend  on  this  to  function. 

“The  key  enabling  technology  behind  the  Red  Team  and  SciAutonics  II  was  a  priori  terrain  mapping. 

Both  teams  acquired  Digital  Terrain  Elevation  Data  (DTED)  maps  of  the  entire  event  course...  ” 

-  Insider’s  View  of  the  2004  DARPA  Grand  Challenge 

So  how  do  these  systems  get  this  vital  information?  Many  use  a  combination  of  local  sensor-suites  on  the  vehicle  and 
an  a  priori  database  of  local  terrain  information.  The  local  sensors  generally  acquire  higher  resolution  data  but  in  a 
much  smaller  region  (10’s  of  meters  from  the  vehicle),  whereas  the  a  priori  database  tends  towards  lesser  resolution  but 
at  a  larger  scope  (10’s  of  kilometers  for  a  given  region).  Typically  the  map  data  (a  priori  database)  is  used  for 
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determining  the  overall  path,  and  the  sensor  data  is  used  to  correct  for  dynamic  environment  changes  (fallen  trees,  large 
racks,  other  vehicles,  etc..) 

Where  does  this  a  prori  information  come  from?  The  National-intelligence  Geospatial  Agency  (NGA)  is  the  DOD 
provider  for  geospatial  information.  They  provide  the  elevation  and  imagery  data  that  feed  current  automated  robotic 
path  planners.  Current  turnaround  time  on  generating  an  elevation  database  or  segmenting  an  image  into  features  is  on 
the  order  of  months  and  is  labor  intensive.  This  required  amount  of  time  and  manpower  will  not  meet  the  needs  of  the 
future  force. 

"...  the  Army  has  insufficient  capabilities  to  generate  the  Future  Force  common  operating  terrain  and  weather  effects  database  ...” 

-  Spatial  Data  Formats  for  Unmanned  Military  Vehicles 

What  if  the  feature  extraction  portion  could  be  automated?  This  paper  not  only  looks  at  the  possible  difficulties  and 
benefits,  but  delves  into  what  has  already  been  done  and  highlights  the  results  of  recent  field  tests. 

2.  PROGRAM  ORIGIN 

Vehicle  navigation  has  changed  dramatically  over  the  past  50  years.  The  1950s  gave  way  to  the  Inertial  Navigation 
System  (INS),  providing  vehicle  operators  with  their  heading  and  speed.  In  the  1960s  the  Navy  Navigation  Satellite 
System  (NNSS),  or  Transit,  became  operational  providing  a  two-dimensional  (latitude,  longitude)  positioning  using  the 
Doppler  shift  of  the  signal.  Follow  on  work  provided  three-dimensional  (longitude,  latitude,  altitude)  positioning  in  the 
1970s.  The  1980s  lead  way  to  the  Global  Positioning  System  (GPS)  and  differential  GPS  (DGPS).  In  the  1990s  the 
Wide  Area  Augmentation  System  (WAAS)  lead  the  way  to  Wide-Area  DGPS  (WADGPS)  and  the  United  States  offers 
to  make  GPS  standard  positioning  service  (SPS)  available  to  the  international  community. 

Since  the  early  90s  there  has  been  research  conducted  at  U.S.  Army  Tank  Automotive  Research,  Development  and 
Engineering  Center  (TARDEC)  and  Army  Research  Labs  (ARL)  on  semi-autonomous  and  autonomous  vehicle 
navigation.  One  of  these  joint  initiatives  was  the  DEMO  III  program.  In  this  program  semi-autonomous  navigation  was 
demonstrated  using  scout-sized  unmanned  vehicles  capable  of  basic  off-road  semi-autonomous  operation  during  day  or 
night.  Poor  weather,  unpredicted  terrain  anomalies,  and  information  overload  in  cluttered  areas  effected  system 
performance.  The  Vetronics  Technology  Integration  (VTI)  program  leveraged  these  Demo  III  technologies  and 
integrated  them  on  two  STRYKER  Infantry  Carrier  Vehicles  (ICVs)  to  demonstrate  military  significant  operations.  The 
factors  that  effected  semi-autonomous  navigation  in  Demo  III  are  mitigated  in  VTI  by  implementing  a  leader-follower 
approach.  The  first  STRYKER  vehicle  is  the  Crew  integration  and  Automation  Testbed  (CAT).  This  is  a  manned 
leader  vehicle  that  lessens  the  computational  requirements  for  semi-autonomous/autonomous  navigation  by  allowing  a 
manned  vehicle  to  plot  a  safe  course.  The  other  STRYKER  is  the  Robotic  Follower  (RF).  This  is  an  unmanned 
platform  that  follows  paths  laid  out  by  the  CAT,  including  those  with  significant  spatial  and  temporal  separations. 

Both  vehicles  have  the  same  sensor  suite  and  could  be  interchanged  in  the  leader  follower  roles.  They  are  also  both 
capable  of  individual  semi-autonomous  navigation  utilizing  Digital  Topographic  Elevation  Database  (DTED)  data  and 
known  terrain  features.  However,  this  approach  is  limited  to  availability  of  known  terrain  features. 

The  goal  of  the  RIUGV  project  is  to  provide  terrain  features  in  an  automated  near-real  time  fashion  for  areas  where  no 
previous  terrain  or  leader  route  data  exists.  A  number  of  government  and  Commercial-off-the-Shelf  (COTS)  software 
modules  where  combined  to  create  this  capability. 

2.1  eCognition 

The  first  version  of  eCognition  was  introduced  to  the  worldwide  market  in  autumn  2000.  Over  a  period  of  only  4  years, 
eCognition  has  proved  to  be  a  quantum  leap  in  the  realm  of  digital  remote  sensing.  It  is  now  possible  to  handle 
complex  classification  problems,  which  require  the  consideration  of  local  context  information  or  other  spatial  data  sets. 
eCognition  is  the  world’s  only  software  for  contextual  classification  of  earth  observation  imagery. 

Due  to  its  unique  capabilities  eCognition  is  used  for  a  wide  range  of  applications  such  as:  environmental  and  natural 
resources  monitoring,  forestry,  agriculture,  defense  and  intelligence,  pipeline  monitoring,  urban  mapping,  natural  hazard 


detection,  coastal/marine  mapping,  exploration  &  mining,  and  disaster  management.  All  products  feature  the  unique 
Object  Oriented  Image  Analysis  technology. 

2.2  Wizard  for  Advanced  Feature  Extraction  (WAFE) 

Detailed  land  cover  analysis  of  remote  areas  is  necessary  for  many  mission  planning  applications.  This  information  can 
be  derived  from  remote  sensing  imagery.  Up  until  now  image  analysts  have  extracted  the  relevant  features  from  this 
imagery  in  a  time  consuming  manual  process. 

In  2002,  Defmiens  Imaging  performed  their  first  feasibility  study  (WAFE  I)  to  determine  if  features  could  be  extracted 
from  commercially  available  data  in  a  highly  automated  fashion.  The  main  focus  was  on  using  high  resolution,  optical 
spaceborne  data,  which  was  acquired  by  the  two  satellites  -  IKONOS  and  Quickbird.  Based  on  the  results  of  this 
study;  it  became  evident  that  the  cabibilty  to  automatically  generate  a  mobility  database  would  be  of  great  benefit. 

Under  the  WAFE  II  contract  (2003  and  2004)  Definiens  Imaging  started  the  development  of  eCognition  WAFE,  a 
customized  version  of  eCognition  enterprise.  eCognition  WAFE  is  designed  to  globally  extract  advanced  features  as 
input  for  a  mobility  database  with  minimum  ground  measurements.  The  software  will  interoperate  with  the  routing 
systems  for  unmanned  ground  vehicles. 

The  architecture  of  eCognition  WAFE  follows  the  hierarchical  &  modular  concept  of  cognition  technology.  Therefore, 
the  concept  supports  continuous  updating  and  refining  of  an  initial  mobility  database  using  multi-source  and  multi¬ 
temporal  information. 

The  initial  mobility  database  relies  on  publicly  available  information,  such  as  weather  information,  Zobler  soil  data, 
worldwide  available  spaceborne  imagery,  and  a  Digital  Elevation  Map  (DEM).  Thus,  this  mobility  database  can  be 
generated  anywhere  in  the  world  with  similar  accuracy. 

WAFE  II  was  finished  in  2004  with  the  first  prototype  of  eCognition  WAFE.  It  uses  IKONOS  data  for  land  cover 
analysis,  a  digital  height  model  from  SRTM  data,  Zobler  soil  type  information  from  USGS  and  weather  information 
from  public  METAR  data.  Using  this  commercially  available  remote  sensing  information  the  eCognition  WAFE 
prototype  automatically  generates  an  initial  mobility  database.  This  mobility  database  is  already  accurate  and  detailed 
enough  to  seed  the  route  planning  of  unmanned  vehicles. 

The  WAFE  prototype  enables  a  continuous  updating  and  refinement  of  this  initial  map.  Additional  information  from 
LADAR  can  be  used  to  get  more  detailed  information  on  surface  roughness.  New  Ikonos  imagery  can  be  used  to  see 
changes  within  the  land  cover  or  get  information  for  cloudy  regions  from  a  prior  data  take.  This  capability,  to  integrate 
airborne  LADAR  data,  was  shown  at  an  earlier  test  at  Fort  Dix. 

During  the  WAFE  II  development  period,  a  significant  portion  of  work  was  dedicated  to  the  interoperability  of  a  fully 
automatic  routing  system.  Future  developments  plan  to  extend  the  capability  of  eCognition  WAFE  to  extract 
information  from  on-board  sensors  of  the  UGV  and  use  this  information  to  continuously  refine  and  improve  the 
mobility  database  with  each  measurement.  Furthermore  the  applicability  of  eCognition  WAFE  to  other  areas  in  the 
world  and  during  different  vegetation  periods  will  be  increased. 

2.3  Pathfinder 

The  Pathfinder  route  planning  and  arc-node  network  generation  algorithms  were  developed  under  the  Footprint  to 
Pathfinder  (F2P)  project.  This  project  was  funded  through  the  Urban  Operations  Focus  Area  Collaborative  Team  (UO 
FACT)  and  was  a  three-year  effort  that  started  in  Fiscal  Year  2002.  F2P  was  started  to  support  computer  generated 
forces  development  and  focused  incorporation  of  its  products  into  two  emerging  simulations:  COMBATXXI  and  One 
Semi  Autonomous  Force  (OneSAF)  Objective  System  (OOS).  Algorithms  were  developed  for  characterizing  urban 
footprints,  assessing  structural  damage  (including  rubble  generation  in  urban  terrain  subjected  to  conventional  weapons 
attack),  ground  vehicle  mobility  and  determining  routes  for  ground  vehicles  through  the  urban  environment. 


The  problem  of  routing  vehicles  in  an  urban  environment  initially  concentrated  on  solving  the  routing  problem  on  the 
road  network,  and  has  gradually  incorporated  open  areas  such  as  parks  and  parking  lots.  The  difficulty  with  of  finding  a 
path  in  space  has  led  to  the  use  of  graph  search  methods  to  solve  this  problem.  An  arc-node  network  is  used  to 
mathematically  represent  the  areas  of  navigation  and  the  A*  algorithm  is  used  to  find  the  “best”  path  through  the 
network  given  starting  and  ending  coordinates.  Constraints  can  be  imposed  such  as  no  go  areas,  restricting  movement 
through  an  axis  of  advance,  specifying  intermediate  waypoints  that  the  vehicle  must  pass,  specifying  known  obstacles 
that  can  limit  or  hinder  vehicle  movement,  and  the  consideration  of  perceived  threat  locations. 

A  network  generator  was  also  developed  to  generate  an  arc-node  network  from  terrain  databases.  Initially,  compact 
terrain  databases  (CTDB)  were  used  as  a  source.  This  was  changed  to  the  00 S  Environment  Runtime  Component 
when  the  COMBATXXI  development  team  switched  to  this  format.  For  the  RIUGV  test,  a  network  generator  was 
developed  to  handle  the  shape  file  format.  Because  COMBATXXI  was  chosen  as  the  demonstration  platform  to 
interface  with  the  route  planning  and  network  generation  algorithms,  all  code  was  written  in  Java. 

2.4  Standard  Mobility  Modeling  Suite  (STNDMob) 

The  STNDMob  was  developed  for  the  Army  as  a  means  to  bring  consistency  of  ground  vehicle  mobility  modeling 
predictions  to  the  model  &  simulation  (M&S)  community.  However,  because  it  is  a  derivation  of  the  NATO  Reference 
Mobility  Model,  the  STNDMob  brings  consistency  with  the  test  and  experimentation,  acquisition,  and  battle  command 
communities  as  well.  Each  module  of  the  STNDMob  suite  is  tailored  to  meet  the  special  needs  of  each  user,  but  are 
tied  to  the  same  core  capability  to  predict  the  maximum  terrain-limited-speed  of  a  given  ground  vehicle.  Since 
STNDMob  is  designed  as  an  Application  Programmer’s  Interface,  it  is  fairly  easy  to  integrate  in  other  applications. 

3.  RESULTING  PRODUCT 


RIUGV  integrated  the  capabilities  of  eCognition  WAFE,  Pathfinder,  and  the  Standard  Mobility  Modeling  Suite  with  an 
existing  government-owned  graphics  user  interface  (Falcon  View).  Generation  of  the  mobility  map  information  (Fig.  1) 
was  automatic  and  derived  from  the  latest  pass  imagery  of  the  IKONOS  satellite  on  the  test  site  (Fig.  2). 


The  Ecognition  WAFE  combination  was  passed  the  raw  satellite  imagery  and  generated  a  detailed  object  level  shape 
file  map  from  this  and  the  other  metadata  previously  discussed  (soil  maps,  local  weather  information,  etc).  This  map 
could  then  be  used  by  the  Automated  Route  Planner.  An  optimized  route  for  user  selected  end  points  and  interim  way 
points  was  then  generated,  with  the  estimated  speed  made  good  and  route  traversal  time  for  the  route  estimated  by 
vehicle  specific  calls  to  the  Standard  Mobility  Modeling  Suite. 


The  output  of  the  process  consisted  of  a  series  of  lat-long  coordinates  to  be  executed  by  the  UGV,  along  with  an 
estimate  of  maximum  speed  and  traversal  time  for  each  portion  of  the  route.  The  combined  product’s  ability  to 
accurately  characterize  the  prospective  route  was  the  principal  question  examined  during  the  live  UGV  testing.. 


Automatic  Workflow  for  WAFE  Live  Test 


landuse.dcp  i 
landuse.shp^^ 


manualgis.shp  |  clouds  ~| 


-►cloud  replacement.dcp 


X 


<cbuds  replacedshg>- 


DEM 


I  # 

M  SI  A^X 

Mobility  Database.shp  / 


V _ w 


^^obstacles.shp^> 


cl.  moving  targets) 


Figure  1 :  Workflow  Process  for  UGV  Live  Test 


Figure  2:  Workflow  Process  for  UGV  Live  Test 


3.1  eCognition  WAFE 


Test  preparations  included  the  acquisition  of  pre-test  IKONOS  imagery  of  the  test  site  and  the  generation  of  a  mobility 
data  base,  as  a  fall  back  position  in  case  of  partial  or  full  cloud  cover  during  the  test  period..  Also  Shuttle  Radar 
Topography  Mission  (SRTM)  data  was  acquired  to  get  a  high  resolution  digital  terrain  map  to  calculate  terrain 
roughness  and  slope. 

The  IKONOS  data  take  for  the  live  test  was  requested  within  a  5  day  time  window  before  the  actual  planned  run  of  the 
UGV.  The  actual  test  data  take  was  successfully  acquired  by  IKONOS  with  little  cloud  cover  and  was  provided  to 
Definiens  Imaging  through  ftp  by  European  Space  Imaging  within  a  4  hour  window.  Using  the  customized  software, 
eCognition  WAFE,  basic  land  cover  polygons  were  fully  automatically  extracted.  Each  polygon  was  classified  as:  water 
body  of  various  types,  forest  of  various  types  and  heights,  smooth  and  rough  low  vegetation,  road  and  trails  of  various 
types  or  man  made  targets.  For  all  road  polygons  the  centerlines  were  identified  and  provided  as  a  line  shape  file. 
Elevation  data  was  derived  from  the  high  resolution  digital  elevation  model  based  on  X-band  SRTM  data  provided  by 
German  Aerospace  Centre  (DLR)  to  Definiens  Imaging  -  the  roughness  of  the  terrain  was  included  and  also  estimated 
by  the  software. 

eCognition  WAFE  automatically  created  a  vehicle  specific  mobility  database  from  this  data  (Fig.  3).  All  object 
polygons  in  this  database  were  tagged  with  the  appropriate  source  image,  land  cover,  terrain  slope,  weather  information 
and  USGS  soil  type  data.  The  system  demonstrated  the  ability  to  derive  a  high  accuracy  mobility  map  for  the  test  area 
within  5  hours  of  the  actual  image  take.  Preliminary  testing  has  also  shown  that  the  technology  scales  well  over 
extremely  large  areas  (i.e.  full  satellite  image  tiles  of  100x100  Km),  with  total  processing  time  being  a  function  of 
image  complexity.  Several  ‘flavors’  of  the  mobility  map  were  generated  to  examine  the  location  accuracy  of  the 
derived  objects:  one  with  just  image  provider  rectification,  one  with  correlated  imagery  improved  rectification,  and  one 
with  six  additional  ground  rectification  measurements. 


Figure  3:  Fort  Knox  mobility  database  generation 


Using  6  ground  control  points,  the  resulting  shape  file  was  re-georectified  using  ArcGIS.  The  object-based  approach  let 
it  appear  feasible  that  the  rectification  process  can  be  provided  with  high  accuracy  with  minimum  amount  of  ground 
measurements.  Next  developments  will  focus  on  advanced  and  highly  atomized  registration  to  ensure  the  necessary  geo¬ 
spatial  accuracy. 

Following  the  generation  of  the  map  file,  the  Falcon  View  GUI  and  Pathfinder  were  given  two  user  selected  routes  for 
generation  -  one  cross  country  (Fig.  4  &  5)  and  one  road  bound  (Fig.  6).  The  lat/lon  coordinates  generated  by  the 
combined  software  suite  for  these  routes  were  downloaded  to  a  memory  stick  and  loaded  into  the  executive  software  of 
the  UGV  employed  in  the  test  environment. 


Figure  5:  Generated  off-road  path  displayed  in  Falconview 


Figure  6:  Generated  road  bound  path  displayed  in  Falconview 


The  Standard  Mobility  Modeling  Suite  also  generated  speed  estimates  and  segment  traversal  times  for  each  portion  of 
the  selected  route.  The  exemplary  routes  illustrated  in  Figures  4&5  consisted  of  approximately  160  GPS  coordinates 
with  matching  speeds  and  traversal  times.  Examination  of  the  accuracy  of  these  estimates  was  not  an  immediate  test 
objective,  but  will  likely  be  examined  in  2005  testing. 


Further  tests  on  Fort  Dix  (Fig.  7)  showed  the  advantage  of  the  hierarchical  and  modular  software  architecture:  If  more 
detailed  information  is  available  as  airborne  LADAR  data,  the  mobility  data  base  can  be  successively  refined  without 
any  changes  in  the  methods  for  the  initial  data  base  creation  and  without  multiple  calculations. 


Figure  7:  Drivability  map  of  a  Fort  Dix  range  based  off  LADAR  data 


3.2  Pathfinder 

Pathfinder  finds  a  route  for  individual  ground  vehicles  on  an  arc-node  network.  The  arc-node  network  is  a 
representation  of  the  roads  and  traversable  off-road  areas.  The  network  is  generated  using  two  sources:  shape  files  and 
Digital  Terrain  Elevation  Data  (DTED)  files.  The  shape  files  contain  polygons  representing  the  features  on  the  terrain, 
e.g.,  roads,  forested  areas,  rivers,  buildings,  open  areas,  etc.  Associated  with  each  polygon  is  data  such  as  soil  type 
needed  to  determine  the  speed  of  a  vehicle  traversing  that  polygon.  In  addition,  the  polygons  are  flagged  as  “go/no  go” 
to  allow/avoid  routing  the  vehicle  through  the  feature  (Fig.  8).  For  example,  a  feature  such  as  a  road  or  open  area  would 
be  flagged  “go”  while  a  building  or  a  ditch  would  be  flagged  “no  go”.  The  DTED  files  contain  elevation  postings 
needed  to  determine  slope,  another  factor  for  determining  vehicle  speed. 
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Figure  8:  Determination  of  go/no-go  areas  for  RIUGV  mobility  Database 


Currently,  network  generation  involves  generating  the  road  network  and  the  off-road  areas  separately  and  then  merging 
the  two  networks  into  one.  The  road  network  is  presently  constructed  manually  using  a  simple  graphical  user  interface. 
With  the  road  polygons  displayed  on  the  screen,  nodes  are  placed  at  intersections  and  along  curves  in  the  road  to  break 
the  curves  into  a  series  of  short  linear  segments.  The  nodes  are  then  linked  by  the  arcs.  The  off-road  network  is 
generated  automatically. 


A  vehicle  in  an  off-road  area  could  possibly  move  in  an  infinite  number  of  directions.  This  must  be  restricted  in  order 
to  reduce  the  number  of  possible  paths  that  may  potentially  be  examined  when  searching  for  the  optimal  path.  In 
addition  there  are  an  infinite  number  of  locations  that  the  vehicle  may  occupy.  This  must  be  reduced  to  a  finite  number 
of  points  and  must  be  as  small  as  possible  without  compromising  the  optimality  of  the  path. 

To  achieve  these  goals,  the  off-road  areas  are  subdivided  into  square  girds.  A  node  is  placed  in  the  center  of  each  grid. 
Arcs  link  the  node  of  a  grid  to  the  nodes  of  the  grids  that  are  physically  adjacent  to  the  given  grid.  Therefore,  it  is 
possible  to  go  in  eight  directions  (less  if  the  grid  is  along  the  border  of  the  terrain)  from  a  node.  The  grid  size  was  set  to 
ten  meters  for  each  side.  (This  worked  well  for  the  Stryker  UGV,  but  for  a  smaller  UGV  a  smaller  grid  size  should  be 
considered.) 


The  merging  of  the  road  network  with  the  off-road  network  was  also  an  automated  process.  Transition  points  were  set 
up  along  roadways  where  the  road  and  off-road  areas  met  to  allow  vehicles  to  move  from  one  medium  to  the  other. 


The  arc-node  network  is  a  directed  graph  where  each  arc  ay  from  node  i  to  node  j  has  a  real  valued,  non-negative  cost 
Cy.  The  problem  is  to  find  the  shortest  path  from  a  source  node  s  to  a  terminus  node  t  by  solving: 
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Where :  N  =  total  number  of  nodes, 

/,  j  =  nodes, 

Cij  =  the  cost  of  travel  to  node  j  from  node  i  (>  0), 

Xij  =  1  if  i  and  j  are  on  the  shortest  path,  0  otherwise, 

Si  - 1  if  /  =  s,  - 1  if  /  =  t,  0  otherwise. 

Equation  1 :  Shortest  path  determination 

The  A*  algorithm  is  commonly  used  to  solve  this  problem  in  the  context  of  finding  the  optimal  path  for  ground 
vehicles,  and  this  algorithm  is  implemented  in  Pathfinder.  The  cost  of  traversing  an  arc  is  adapted  from  COMBATXXI. 
It  considers  two  factors,  travel  time  and  risk  from  perceived  threats.  Travel  time  is  a  function  of  speed  and  distance. 
Distance  is  obtained  from  the  arc’s  length  and  speed  is  obtained  from  calling  the  Standard  Mobility  API.  The  risk  is 
obtained  from  threat  circles  laid  over  the  network.  A  threat  circle  is  a  circular  area  where  a  threat  is  perceived  to  exist. 
A  weight  from  1  to  100  is  assigned  to  the  threat  circle  where  larger  values  are  associated  with  higher  risks  for  the 
vehicle  traveling  through  the  circle.  The  risk  is  zero  outside  the  threat  circle.  The  total  arc  cost  is: 

Cij  =  (Wtravel*Ty)  +  (Wrisk*Rij) 

0  <  Wtravei  <  1 

0  <  wrisk  <  1 

^travel  ^  W risk  ~  1 

Ty  =  travel  time  component  (normalized) 

Ry  =  risk  component  (scale  from  0  to  100) 

Equation  2:  Arc  cost  determination 

Wtravei  and  Wrisk  are  weights  applied  to,  respectively,  the  travel  and  risk  components  of  Cy.  They  are  used  to  determine 
how  much  each  component  contributes  to  the  overall  cost.  For  example,  if  a  route  is  needed  for  a  vehicle  within  an  area 
where  it  is  seen  to  be  secure  from  any  threat,  travel  time  becomes  the  only  factor  to  consider  in  the  arc’s  total  cost,  so 
Wtravei  is  set  to  1  and  Wrisk  is  set  to  0.  If  travel  and  risk  contribute  equally  to  the  total  cost,  both  Wtravd  and  Wrisk  are  set  to 
0.5. 

It  should  be  noted  that  this  cost  function  is  not  “hard-wired”  into  the  A*  algorithm  code.  A  cost  function  class  was 
written  and  an  instance  of  this  class  was  passed  to  the  A*  code.  If  a  different  cost  function  is  required,  a  separate  cost 
function  class  can  be  written.  It  can  then  be  instantiated  and  passed  to  the  A*  code.  This  allows  a  library  of  cost 
functions  to  be  maintained  and  eliminates  rewriting  the  A*  code  whenever  a  new  cost  function  is  introduced. 

The  capability  exists  to  consider  other  constraints.  Although  these  were  not  used  during  the  RIUGV  test,  short 
descriptions  of  two  additional  constraints  are  presented  here.  The  first  constraint  is  the  no-go  area.  It  is  a  polygon  that 
is  laid  over  the  network.  If  a  situation  arises  where  a  vehicle  is  prohibited  from  entering  a  certain  area  (either  for 
military  or  political  reasons),  a  no  go  area  polygon  can  be  created  to  delineate  that  area.  The  route  planning  algorithm 
will  not  consider  any  arc  wholly,  or  partially,  located  within  the  no-go  area.  The  second  constraint  is  the  axis  of 
advance.  It  is  defined  as  “a  line  of  advance  assigned  for  purposes  of  control;  often  a  road  or  a  group  of  roads,  or  a 
designated  series  of  locations,  extending  in  the  direction  of  the  enemy.”  It  is  implemented  as  a  polygon  that  encloses  a 
series  of  arcs.  Vehicle  movement  is  restricted  to  only  those  arcs  and  nodes  that  lie  within  the  polygon.  The  vehicle 


enters  the  axis  of  advance  through  a  designated  node  called  the  checkpoint  node.  This  node  is  located  inside  the 
polygon  and  it  is  characterized  by  the  fact  that  it  has  an  arc  linked  to  a  node  outside  the  polygon. 

The  checkpoint  node  becomes  the  first  node  that  a  vehicle  visits  inside  the  polygon.  The  vehicle  exits  the  axis  of 
advance  through  one  or  more  designated  exit  nodes.  An  exit  node,  like  a  checkpoint  node,  is  located  inside  the  polygon 
and  has  an  arc  linked  to  a  node  outside  the  polygon.  The  exit  node  becomes  the  last  node  the  vehicle  visits  before 
leaving  the  polygon.  The  purpose  of  the  exit  node  is  to  force  the  route  planning  algorithm  to  search  in  the  direction  the 
vehicle  is  intended  to  move  through  the  axis  of  advance. 

Given  these  specifications,  the  route  planning  algorithm  breaks  the  problem  up.  It  first  determines  the  least  cost  path 
from  the  source  node  to  the  checkpoint.  Once  in  the  axis  of  advance,  the  algorithm  tries  to  find  the  least  cost  path  from 
the  checkpoint  to  the  exit  node,  considering  only  those  arcs  and  nodes  within  the  polygon.  The  algorithm  finally  finds 
the  least  cost  path  from  the  exit  node  to  the  terminus.  If  multiple  exit  points  are  specified,  the  algorithm  chooses  the 
least  cost  alternative  between  routes  from  the  checkpoint  to  each  exit  node  and  then  on  to  the  terminus. 

3.3  Standard  Mobility  Modeling  Suite 

One  module  of  STNDMob  is  used  in  conjunction  with  the  Pathfinder  algorithm  to  pre-process  all  possible  maneuver 
routes  in  the  selected  area  given  typical  terrain  conditions.  The  STNDMob  acted  as  a  service  to  the  Pathfinder 
algorithm  to  predict  the  maximum  speed  of  the  UGVgiven  the  terrain  conditions  provided  by  Pathfinder. 

A  second  module,  designed  to  execute  faster,  works  with  the  real/near-real  type  navigation  system  to  predict  terrain- 
limited  speeds  due  to  dynamic  changes  in  the  environment.  This  module  was  written  in  the  programming  language 
C++,  rather  than  Java  as  the  other  modules  are  written  with,  in  order  to  obtain  faster  execution.  This  particular  module, 
referred  to  as  STNDMob-Lite,  predicts  a  maximum  speed  of  the  UGV,  but  the  speed  is  capped  at  the  controlled  speed 
of  the  UGV.  Thus,  at  the  fairly  low  speeds  permitted  for  the  experiment  the  model  serves  to  provide  the  navigation 
system  with  go  and  no-go  predicitons  for  all  practial  purposes  (Fig  9). 


Figure  9:  STNDMob  GUI  and  mobility  determination  example 

4.  TEST  RESULTS 

RIUGV  Engineering  and  Evaluation  Tests  (EETs)  were  conducted  at  Fort  Knox  October  1 1th  -  15th  as  part  of  Vetronics 
Technology  Integration  (VTI)  Operational  Testing.  Unmanned  vehicle  navigation  tests  were  conducted  on  the  1 1th  and 
site  surveys  were  performed  12th  -  15th.  System  performance  was  measured  according  to  the  following  metrics. 

•  Positional  accuracy  of  extracted  features 

•  Accuracy  of  predicted  soil  and  vegetation  states 

•  Accuracy  of  predicted  road  centerlines 

•  Accurate  classification  of  mobility  impediments 

•  Feasibility  of  traversal  of  generated  paths 


4.1  Positional  accuracy  of  extracted  features 

Feature  accuracy  was  found  to  be  a  measure  of  position  in  the  image,  number  of  correlated  images,  and  number  and 
location  of  rectification  points  incorporated  into  the  scene.  Objects  located  in  the  geometric  center  of  the  image  or  the 
center  of  rectification,  when  incorporated,  were  more  precisely  positioned  (~  3.5  meters)  than  objects  outside  this 
region.  When  multiple  images  were  leveraged  in  the  production  of  the  feature  map,  ground  truth  accuracy  was  found  to 
increase  to  a  similar  degree  (-3  m).  However,  the  key  to  accurate  positioning  was  the  insertion  of  surveyed  rectification 
points.  Through  the  insertion  of  these  surveyed  points,  object  accuracy  was  resolved  to  sub-meter  or  near  sub-meter 
levels  (Fig.  10).  The  position  and  number  of  rectification  points  were  understood  to  be  important  during  the  collection 
process  and  selected  to  produce  the  expected  best  results  (Fig  11).  No  data  was  collected  to  conduct  a  study  to 
determine  the  ideal  number  or  position  of  these  points. 


On  average,  a  non-rectified  scene  had  accuracies  between  5-10  meters  while  a  rectified  scene  had  accuracies  between 
sub  and  1.5  meters.  A  certain  level  of  uncertainty  was  introduced  to  these  measurements  in  the  experimental  procedure. 
Vehicle  tasking  did  not  allow  for  ground  truth  and  rectification  measurements  to  be  taken  with  the  vehicles  GPS  unit. 
This  introduces  potential  drift  between  receiver  estimates.  Also,  ground  truth  and  rectification  points  were  based  off 
single  GPS  readings  rather  than  an  average  of  readings  taken  over  an  extended  period  of  time. 


RIUGV  Location  (UTM): 
4188205.396215  N 
607079.798616  E 

Surveyed  Position  (UTM): 
4188204.8  N 
607080.5  E 

Difference  (Meters): 

.58m 

.70m 


Figure  10:  Survey  vs  RIUGV  location  of  a  HMWWV 


Figure  11:  Ground  Rectification  Points 


4.2  Accuracy  of  predicted  soil  and  vegetation  states 

Vegetation  classifications  were  measured  against  Digital  Topographic  Data  (DTOP).  RIUGV  classifications  were  more 
refined  than  the  data  contained  in  the  DTOP  file.  DTOP  contained  basic  definitions  of  vegetation  boarders  while 
RIUGV  extracted  individual  trees.  The  general  vegetative  border  was  the  same  for  both  sources  (Fig  12)  with 
accuracies  as  described  in  section  4.1.  Soil  state  estimates  were  verified  through  visual  verification.  Future  testing  will 


Figure  12:  DTOP  (White  -  roads  and  vegetation)  vs.  RIUGV 
(Green  -  vegetation  and  Red  -  roads)  definition  of  roads  and 
vegetation 


4.3  Accuracy  of  predicted  road  centerlines 


A  fractal  growth  algorithm  was  used  to  find  the  center  of  road  objects.  A  real  world  navigation  test  was  performed  on 
the  road  layer  of  the  data  with  the  VTI  Crew  integration  and  Automation  Testbed  (CAT)  Stryker  UGV  to  test  the 
algorithms  performance.  Roads  were  extracted  with  two  images  correlated  and  rectification  points  incorporated.  The 
RIUGV  path  (Fig.  6)  was  generated  from  two  waypoints  at  the  South  East  and  North  West  comer  of  the  road  network. 
The  generated  path  was  compared  with  DTOP  centerlines  and  human  driven  centerline  data.  DTOP  data  was 
considered  the  control  for  the  experiment.  Results  indicated  deviations  in  accuracy  from  less  than  a  meter  to  3  meters. 
On  average,  the  RIUGV  centerlines  had  a  deviation  from  the  DTOP  centerlines  of  approximately  a  meter  to  a  meter  and 
a  half.  Deviation  was  less  for  human  recorded  centerline  data,  on  the  order  of  a  meter  or  less.  This  can  be  attributed  to 
RIUGV  and  Human  data  being  developed/recorded  specific  to  the  STRYKER  UGV  traversing  the  terrain.  The  DTOP 
data  was  dated  cache  information  (file  generation  date  was  01/18/00,  survey  date  is  unknown)  with  the  recording  means 
unknown.  Nevertheless,  the  DTOP  data  was  considered  the  control  for  the  experiment  due  to  the  low  probability  of 
detailed  platform  specific  road  centerline  data  being  available  during  an  operational  experiment  across  foreign  terrain. 

The  detection  of  road  centerlines  was  not  an  optimized  procedure.  The  inclusion  of  a  smoothing  algorithm  will  provide 
for  a  more  consistent  path.  The  system  does  not  identify/classify  intersections.  Accounting  for  these  situations  will 
improve  the  accuracy  of  generated  routes  through  these  areas. 

4.4  Accurate  identification  of  mobility  impediments 

The  vehicle  mobility  map  was  based  off  of  a  basic  go/no-go  definition  file  (Fig.  8).  This  file  is  a  result  of  the  mobility 
characteristics  of  the  vehicle  (from  STNDMob)  and  terrain  state  (feature  type,  height,  and  weather  conditions).  A  site 
survey  confirmed  that  all  recognizable  mobility  impediments  were  identified  in  the  map.  Recognizable  mobility 
impediments  were  characterized  by  test  engineers  as  those  that  the  vehicle  could  not  traverse  based  off  of  slope  or  type 
(e.g.  body  of  water). 

Two  small  areas’  of  the  map  were  tagged  as  no-go  and  could  not  be  quantified  as  such  by  engineers  (fig  13).  It  is  likely 
that  difference  in  heat  signature  between  terrain  and  surrounding  vegetation  or  expected  soil  moisture  content  were  the 
alarms  that  tagged  these  areas  as  not  traversable. 


Figure  13:  No  quantifiable  no-go  spots 


4.5  Feasibility  of  traversal  of  generated  paths 

An  on-road  and  off-road  RIUGV  path  was  generated  and  traversed  by  the  CAT  UGV  (Fig.  5&6).  These  paths  were 
selected  to  test  particular  attributes  of  the  system  (ability  to  produce  a  long  accurate  on-road  path  containing  multiple 
turns  and  the  ability  to  generate  a  viable  off-road  path  even  through  covered  terrain).  However,  these  paths  were  also 
selected  with  vehicle  and  safety-driver  health  in  mind  (across  areas  with  little  or  no  elevation  change).  Highly 
demanding  paths  were  also  generated  that  contained  multiple  changes  in  elevation  and  other  mobility  impediments. 
These  paths  were  surveyed  by  test  engineers  and  deemed  traversable  by  the  STYKER  UGV.  However,  a  portion  of 
one  particular  path  would  have  presented  an  interesting  mobility  challenge  for  the  UGV.  The  path  generated  required 
the  UGV  to  traverse  a  drainage  ditch  at  its  flattest  point  (Fig  14).  The  ditch  had  a  near  90  degree  change  in  elevation  at 
depths  of  10-12  feet  on  either  side  of  the  selected  path.  The  path  selected  was  a  gradual  change  in  elevation,  due  to 
erosion  of  soil,  that  was  determined  to  be  traversable  by  a  STRKYER.  Given  that  the  STNDMob  mobility  model  used 
was  one  of  a  manned  STRKYER  platform,  this  was  deemed  a  viable  route. 


Figure  14:  Eroded  path  through  the  ditch 


5.  TEST  COMMENTS  AND  FUTURE  PLANS 

The  results  from  this  field  test  have  proven  that  near-real-time  feature  extraction  from  satellite  imagery  is  a  viable  a 
prori  data  source  for  UGV  path  planning.  Additional  rectification  work  (e.g.  number/location  of  rectification  points  for 
a  given  scene)  needs  to  be  conducted  to  provide  the  most  accurate  and  efficient  results.  However,  it  is  feasible  to  expect 
this  work  to  be  conducted  in  the  near  future  and  for  those  results  to  further  verify  this  approach.  For  operations  in 
known  terrain,  where  ground  measurement  data  already  exists  (most  of  the  US  and  Europe),  this  information  can  be 
ingested  from  known  sources  without  the  need  for  survey  data.  Future  work  towards  automatic  rectification  during 
UGV/MGV  traversal  could  eliminate  this  need  altogether. 

Future  plans  for  RIUGV  include  work  that  will  increase  the  accuracy  of  road  centerline  estimations,  classify 
intersections  and  develop  UGV  behaviors  for  these  situations,  and  integrate  near  real-time  UGV  sensor  data  (i.e. 
LADAR,  color  or  IR  cameras).  These  additional  capabilities  were  selected  as  the  most  promising  to  meet  short  term 
VTI  goals.  Additional  future  efforts  could  include  incorporation  of  UAV  sensor  data  and  automated  UGV  based  scene 
rectification. 
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